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(54) Method and apparatus for tracking identity-code changes in a mobile communications 
system 

(57) In a mobile radio network such a GSM network, 
an operative identity code is passed by a mobile station 

to the fixed network part at the start of each com muni- Air au* a 

cation transaction. This operative identity code will ei- 
ther be the unique identity code (IMSI) assigned to the 
mobile-station user or, more usually, a temporary, sub- 
stitute, identity code (TMSI) allocated by the fixed net- 
work part with a view to obscuring the identity of the user 
to anyone monitoring the network radio traffic. Whilst the 
fixed network infrastructure knows the association be- 
tween a temporary identity code (TMSI) and the corre- 
sponding unique identity code (IMSI) of a user, this in- 
formation is generally not readily accessible. To enable 
the current temporary identity code (TMSI) of a user to 
be readily tracked without burdening the network infra- 
structure, a monitoring arrangement is provided which 

monitors network signalling messages to link the differ- FIG. 4 

ent messages associated with a particular user mobile 
station that separately give the current operative identity 
code (line "c") and assign a successor operative identity 
code to that user (line "h"). In one embodiment applica- 
ble to a GSM network, messages on the A interface that 
carry identity code information for a particular user dur- 
ing a communication transaction are linked through the 
local references of the SCCP connection established for 
the transaction. In a second embodiment, also applica- 
ble to GSM, messages on the Abis interface are moni- 
tored and linked through the channel numbers con- 
tained in these messages. 
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Description 
Technical Field 

The present invention relates to a method and ap- 
paratus for tracking identity-code changes in a commu- 
nications system: in particular, but not exclusively, the 
present invention relates to the tracking of changes in 
operative subscriber identity codes in mobile radio sys- 
tems such as systems operating according to the GSM, 
DCS 1800 or PCS 1900 standards. 

For convenience, systems operating according to 
the GSM nnd DCSl 600 standards, including derivatives 
therool. will hereinafter be referred to as "GSM-type" 
systems. DCS 1800 systems themselves being deriva- 
tive ol GSM systems and exhibiting the same charac- 
teristics lor present purposes; it should, however, be 
noted that me present invention is not restricted to GSM- 
type systems 

Background Art 

In mobile radio networks, an operative identity code 
is generally passed by a mobile station to the fixed net- 
work part at the start of each communication transac- 
tion. This operative identity code generally identifies the 
user to the network and for this purpose, each user is 
assigned a unique identity code. However, it is undesir- 
able to have all the transactions of a user marked by the 
user's unique identity code since this permits the user's 
activity to be monitored by listening to the network radio 
traffic. For this reason, temporary identity codes are al- 
located to users by the fixed network part, the fixed net- 
work part being itself aware of the association between 
the temporary and unique identity codes of a user: the 
temporary identity code is then used by a user's mobile 
station as its operative identity code when initiating a 
transaction. 

In principle, it should be a simple matter for the net- 
work operator to ascertain the current operative identity 
code being used by a user as the network infrastructure 
is already aware of the association. However, as a prac- 
tical matter, accessing the information held in the net- 
work infrastructure tor non-standard purposes requires 
substantial modification to existing software with the 
consequent need to re-qualify the software and associ- 
ated systems. 

It is therefore an object of the present invention to 
provide an alternative way of tracking the current opei- 
ative user identity of a particular user. 

As will be more fully set out below, the present in- 
vention involves providing a monitoring method and ap- 
paratus that derives the sought-after information by 
monitoring signalling messages on the network rather 
than by accessing data stored in the network infrastruc- 
ture. Monitoring signalling messages to derive informa- 
tion on a mobile network is not new in itself and may be 
done using, for example, the Hewlett-Packard 37900D 



Signalling Test Set. However, not only is it previously 
unknown to seek to ascertain the current operative iden- 
tity code being used for a user by monitoring network 
signalling messages, but the required information to 
5 track the current operative identity code is generally not 
contained in an individual messages but is spread 
across different messages. 
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Summary of the Invention 



According to one aspect of the present invention, 
there is provided a method of tracking identity-code 
changes in a communications system in which a plural- 
ity of user stations can simultaneously conduct respec- 
ts tive communication transactions during which signalling 
messages are exchanged with the remainder of the 
communication system over at least one signalling path 
of a signalling subsystem of said communications sys- 
tem, said signalling messages including first messages 
20 sent by said user stations and each including an identity 
code associated with the user station sending that mes- 
sage, and second messages specifying corresponding 
identity codes for particular user stations; said method 
comprising the steps of: 



(a) - monitoring said signalling subsystem to detect 
a said first message; 

(b) - extracting from the said first message detected 
in step (a), the said identity code included therein; 

(c) further monitoring said signalling subsystem to 
detect a said second message related to the same 
communication transaction as the first message de- 
tected in step (a); and 

(d) upon detection in step (c) of said second mes- 
sage, recording the identity code specified therein 
as the identity code corresponding to the identity 
code extracted in step (b). 



Typically, the communications system will be a mo- 
40 bile radio network in which users have respective unique 
identity codes and the user stations are mobile stations 
that communicate over radio channels with a fixed net- 
work part forming the aforesaid remainder of the com- 
munications system. In this case, the identity code in- 
45 eluded in a said first message will generally be one of 
(i) the unique identity code of a user associated with the 
user station sending that first message, and (ii) a tem- 
porary identity code assigned by a said second mes- 
sage sent to the user station. The mobile stations (e.g. 
so user handsets) may also have respective unique identity 
codes, in which case one of the identity codes included 
in the first and second messages may be the respective 
unique identity code for a mobile station. 

Generally, step (c) will involve detecting signalling 
55 messages relating to the said same communication 
transaction by looking on a specific signalling path for 
signalling messages that have at least one particular pa- 
rameter value which is at least temporarily characteristic 
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of said same communication transaction on the afore- 
said specific signalling path. 

The said specific signalling path will at least initially 
be the signalling path on which said first message is de- 
tected in step (a); however, the signalling path being 
used in relation to the said same transaction may 
change during the course of the transaction and the 
present monitoring method is preferably operative to de- 
tect such changes and set the said specific signalling 
path accordingly. 

As regards the said at least one particular parame- 
ter value, this is advantageously determined from at 
least one signalling message previously detected on the 
specific signalling path as related to said same commu- 
nication transaction. Thus, in the case of a GSM mobile 
radio system being monitored on its A interfaces, said 
at least one particular parameter value can be the end 
point reference of the SCCP connection set up for the 
communication transaction on said specific signalling 
path; in this case, the said at least one particular param- 
eter value remains the same for as long as said specific 
signalling path is unchanged. For a GSM system being 
monitored on its Abis interfaces, said at least one par- 
ticular parameter value can be the channel number of 
the radio channel being used for the transaction; how- 
ever, this value may be changed during the transaction 
and preferably, therefore, the present monitoring meth- 
od is arranged to track such changes and adjust the said 
at least one parameter value accordingly. 

Preferably, the monitoring method includes the step 
of generating a record for said specific signalling path 
associating the identity code extracted in step (a) with 
the current said at least one parameter value character- 
istic of said same communication transaction on said 
specific signalling path, step (d) involving associating 
the identity code specified in the second message with 
the record. In this case, the method advantageously al- 
so includes the further step of monitoring said specific 
signalling path to detect termination of said same com- 
munication transaction and thereupon removing said 
record. 

Generally, the monitored signalling subsystem will 
have a plurality of said signalling paths and in this case, 
the monitoring method preferably involves carrying out 
steps (a) and (c) by monitoring at least some of these 
signalling paths, and the operation in step (d) of record- 
ing said identity code corresponding to the identity code 
extracted in step (b), preferably involves generating a 
report including both these identity codes and sending 
this report to a station, this station being the same for 
all monitored signalling paths. 

Preferably, the operation in step (d) of recording the 
identity code corresponding to the identity code extract- 
ed in step (b), involves using these identity codes to 
maintain association means, such as a lookup table, as- 
sociating the corresponding current identity codes with 
unique subscriber identities. 

Where the monitored communications system is a 



mobile radio network that extends over a plurality of lo- 
cation areas with temporary identity codes being as- 
signed uniquely within each such area, the method pref- 
erably includes the step of monitoring said signalling 

5 path to identify the current location area of the user sta- 
tions partaking in communication transactions, and re- 
cording the location area of a user station along with its 
identity code. 

Tracking the current identity code of a particular us- 

10 er to whom a unique identity code has been assigned, 
enables the usage behaviour of that user to be moni- 
tored by the following steps: 

(i) tracking identity-code changes in accordance 
is with the embodiment of the invention that maintains 
an association between the unique identity code of 
a user and the corresponding current identity code; 
(it) starting with the said unique identity code of said 
particular user, identifying from said association 
20 means the corresponding current identity code of 
that user; and 

(iii) monitoring said signalling path (or paths) to de- 
tect first messages including the said correspond- 
ing current identity code identified in step (ii), and 
25 recording predetermined parameters of tho com- 

munication transactions of which these first mes- 
sages form a part. 

According to another aspect of the present inven- 
30 tion, there is provided apparatus for tracking identity- 
code changes in a communications system in which a 
plurality of user stations can simultaneously conduct re- 
spective communication transactions during which sig- 
nalling messages are exchanged with the remainder of 
35 the communication system over at least one signalling 
path of a signalling subsystem of said communications 
system, said signalling messages including first mes- 
sages sent by said user stations and each including an 
identity code associated with the user station sending 
•to that message, and second messages specifying corre- 
sponding identity codes for particular user stations; said 
apparatus comprising: 

- first monitoring means for monitoring said signalling 
45 subsystem to detect a said first message; 

- first extracting means for extracting from a said first 
message detected by said first monitoring means, 
the said identity code included therein, 

- second monitoring means for further monitoring 
50 said signalling subsystem to detect a said second 

message related to the same communication trans- 
action as said first message detected by said first 
extracting means, and 

- second extracting means for extracting from a said 
55 second message detected by said second monitor- 
ing means, the identity code specified in that sec- 
ond message as the identity code corresponding to 
the identity code extracted by the first extraction 
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means. 

It will be appreciated that the first and second mon- 
itoring means will generally use the same physical ele- 
ments for listening to the signalling subsystem. 

Brief Description of Drawings 

A method and apparatus for tracking identity-code 
changes in accordance with the present invention, will 
now be described, by way of non-limiting example, with 
reference to the accompanying drawings, in which: 



Figure 1 

Figure 2 

Figure 3A 
Figure 3B 
Figure 4 

Figure 5 
Figure 6 

Figure 7 
Figure 8 

Figure 9 
Figure 10 

Figure 1 1 



is a block diagram showing the main com- 
ponents of a GSM cellular mobile radio 
system; 

is a diagram illustrating the relationship 
between radio cells and location areas in 
the Figure 1 system; 

is a diagram illustrating the format or an 
IMSI subscriber identity code; 
is a diagram illustrating the format of a 
TMSI-based subscriber identity code; 
is a diagram illustrating the signalling 
messages passed botwoon a mobile sta- 
tion and an MSC of the Figure 1 system 
during a location update procedure; 
is a diagram illustrating the layered format 
of the message used to carry the location 
update request in Figure 4; 
is a diagram illustrating the signalling 
messages passed between a mobile sta- 
tion and an MSC of the Figure 1 system 
during a subscriber-initiated service re- 
quest procedure; 

is a diagram illustrating the signalling 
messages passed between a mobile sta- 
tion and an MSC of the Figure 1 system 
during a paging response procedure; 
is a diagram illustrating the processing in 
a monitor probe of messages detected as 
carrying subscriber identity information, 
this processing including the generation 
of report messages; 

is a diagram illustrating the processing of 
report messages received from monitor 
probes to update a table associating IM- 
SIs with corresponding TMSIs; 
is a diagram illustrating the signalling 
messages passed between an MSC and 
two BSCs of the Figure 1 system during a 
handover operation involving a change in 
BSC; and 

is a diagram illustrating the signalling 
messages passed between a BSC and 
two BTSs of the Figure 1 system during a 
handover operation involving a change in 
BTS. 
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Best Mode for Ca rrying Out the Invention 

Overview of a GSM Network 

Figure 1 is a diagram showing the main elements 
of a public land mobile network (PLMN) based on digital 
cellular radio technology; in particular, the Figure 1 net- 
work is a GSM network. 

The Figure 1 network comprises a network and 
switching subsystem (NSS) 10 which connects with a 
plurality of base station subsystems (BSS) 11; the BSS 
provide radio communication with mobile stations 12 
(only one of which is shown in Figure 1). The NSS 10 
also communicates with the fixed public network 1 3 (the 
public switched telephone network PSTN and integrat- 
ed digital services network ISDN). Indeed the PLMN can 
be thought of as an access path to the PSTN/ISDN, 
though calls may also be wholly contained within the 
PLMN. 

Each BSS 11 comprises a base station controller 
(BSC) 17, and a plurality of base transceiver stations 
(BTS) 18 each controlled by the BSC 17. Each BTS 18 
has radio transmitters and receivers for providing radio 
coverage of a local area known as a 'cell'. 

Signalling and user data (digitised voice and other 
digital data such as computer data) pass between each 
mobile station 12 and the BTS 18 of the cell in which the 
mobile station is located. As a mobile station moves 
from one cell to another, control of handover of commu- 
nication with the mobile station from the BTS of the old 
cell to the BTS of the new cell, is effected by the BSC. 

The radio interface between a mobile station and 
BTS is standardised within a particular system such as 
GSM. Similarly, the interface between each BTS 18 and 
its associated BSC 17, by which user data and signalling 
are exchanged between these elements, is also gener- 
ally standardised (in GSM, this interface is known as the 
'Abis' interface). 

Each BSS 11 communicates with a mobile switch- 
ing centre (MSC) 20 of the NSS 10, each MSC 20 gen- 
erally being in communication with several BSS. The in- 
terface between a BSS and an MSC is again generally 
standardised, this interface being known as the 'A' in- 
terface in GSM. 

In GSM networks, user data and signalling are mul- 
tiplexed across the radio interface, the 'Abis' interface 
and the 'A' Interface. However, within the NSS, user data 
and signalling are handled separately. This is shown in 
Figure 1 by depicting user-data paths in solid lines and 
signalling paths in dotted lines; when both use the same 
path, a solid line with superimposed white dots is used. 

In the NSS, the user data is handled by the MSCs 
and for a given call, the user data will commonly travcrso 
two MSCs 20. Although in Figure 1 the MSCs 20 are 
shown as directly connected by a solid line, this should 
be understood merely as showing that user-data traffic 
can pass between the MSCs; in practice, whilst a direct 
connection is used where justified by traffic levels. 
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MSCs may be connected through the intermediary of 
the fixed public network 1 3. 

In addition to the MSCs 20, user data may also be 
handled in the NSS by what in GSM parlance is known 
as a gateway MSC (GMSC) 21 . The purpose of the GM- 
SC 21 is to handle calls set up in either direction be- 
tween mobile stations and outside of the PLMN; thus for 
a call from outside of the PLMN towards a mobile sta- 
tion, the GMSC determines where the call should be 
routed to catch up with the mobile station. In practice, 
GMSC functionality is often provided at each MSC. 

The remaining components of the NSS 10 are con- 
cerned with control functions and these components 
communicate with each other, with the MSCs and GM- 
SC, and with the fixed public network through signalling 
links using a signalling system generally based on the 
SS7 (CCITT Signalling System No.7) standard. Within 
the NSS 10 a GSM system uses the MAP (Mobile Ap- 
plication Part) protocols for non-circuit -related signalling 
traffic and the TUP (Telephone User Pari) and ISUP (IS- 
DN User Part) for circuit-related signalling traffic. Again, 
the signalling paths between components of the NSS 1 0 
are not necessarily direct but will generally make use of 
the SS7 network associated with the fixed public net- 
work. 

The components of the NSS not already described 

are: 

the Home Location Register (HLR) 23 - this con- 
tains information about subscribers registered with 
the PLMN (such as the services available to a par- 
ticular subscriber and the PLMN network address 
of the MSC where the subscriber is currently locat- 
ed); 

the Visitor Location Register (VLR) 24 - generally, 
each MSC has its own associated VLR which holds 
both subscriber data about users currently visiting 
the area covered by the MSC, and data about the 
current location of each user within the MSCs cov- 
erage area; 

the Authentication Register (AuC) 25 - this compo- 
nent is closely associated with the HLR and holds 
data providing for subscriber identification and en- 
cryption of calls; 

the Equipment Identify Register (EIR) 26 - this 
stores information about the mobile stations 12 
themselves; 

the SMS Gateway 27 - in GSM, a special 'Short 
Message Service" is available, this being provided 
through the SMS Gateway. 

Three main control functions may be identified in 
regulating calls in the PLMN (the signalling traffic being 
the communication required to implement these func- 
tions). These three functions are: 

radio resource management - this is the task of 
establishing, maintaining and releasing stable con- 



B 

nections between mobile stations and an MSC de- 
spite movements of a mobile station. This manage- 
ment function primarily involves the BSCs but also 
the BTSs and MSCs. 

s - mobility management -this is the task of maintain- 
ing up-to-date user location information so as to 
permit incoming calls to be routed to the appropriate 
mobile station; in GSM, the address of the MSC in 
the area of which a user is to be found , is stored in 

10 the user's HLR whilst the user's location within that 
area is held in the VLR associated with the MSC. 
This management function involves the MSCs/ 
VLRs and the HLR. 

call management - this task involves, as well as 
*5 the usual control of calls as found in the fixed public 
network, the routing of calls towards a mobile sta- 
tion when the location of the latter is initially not 
known. In GSM, for calls towards a mobile station 
from outside of the PLMN in which the user of the 
20 mobile station is registered, it is the task of the GM- 
SC to find out from the home HLR of the user being 
called, where that user is and then appropriately 
route the incoming call. The call management func- 
tion involves the MSC/VLR, HLR and GMSC. 

25 

Location Areas and Location Updating 

Turning now to Figure 2, this Figure shows a pattern 
of hexagonal cells each representing a corresponding 

30 radio cell, that is. the coverage area of a BTS (assuming 
that each BTS only covers one area). In Figure 2 only 
eight cells have been specifically labelled, these being 
cells C1 to C8. 

Groups of radio cells (generally, but not necessarily, 

35 physically adjacent) are logically associated, the result- 
ant coverage areas being referred to as "location areas". 
Thus, cells C 1 to C 8 are grouped together and cover 
a location area L1. In Figure 2, six location areas L1 to 
L6 are shown. 

-to in GSM systems, the cells associated with each 
MSC (that is, the cells associated with the BTSs of the 
BSSs connected to.the MSC concerned) are divided into 
one or more location areas with the only limitation being 
that no location area can contain cells associated with 

4S more than one MSC. Thus, in Figure 2 the cells associ- 
ated with the upper MSC 20 form three location areas 
L1 to L3, whilst the cells associated with the lower MSC 
20 form a further three location areas L4 to L6. 

It is worth nothing that the GSM standards do not 

so themselves require that all the cells associated with a 
particular BSS 11 are in the same location area but this 
will often be the case. 

The purpose of grouping cells into location areas is 
to facilitate the task of mobility management. In order 

ss for a mobile station to be located to receive an incoming 
call, two basic approaches are possible. Firstly, a paging 
message could be transmitted in every cell of the PLMN 
in order to have a searched-for mobile station respond 
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to identify its position; such an approach is, however, 
very inefficient. The second approach is to have the 
PLMN store location information on each user which is 
periodically updated as the user (or rather, his mobile 
station) moves around the network. This latter approach 
is the one most usually taken. However, if a location up- 
date is effected every time a mobile station moves from 
one cell to another, a very large amount of signalling 
traffic would be created. In order to avoid this problem, 
GSM uses the concept of a location area with a mobile 
station only initiating a location update when it deter- 
mines it has changed location area. Since the PLMN 
now knows the location area of each mobile station, 
when it is necessary to route an incoming call to a par- 
ticular mobile, it is only necessary to transmit a paging 
message in the cells of the relevant location area. 

As previously indicated, location information is ac- 
tually stored in two parts with the address of the MSG 
in whose area a mobile station is currently located being 
stored in the HLR, and the local location information 
(that is, current location area) being stored in the VLR 
associated with that MSC. 

A mobile station can tell when it has changed loca- 
tion area because the BTS of each cell periodically 
transmits the identity of the cell and location area in 
which it is located; by storing this location area informa- 
tion, the mobile station can readily tell when it changes 
location area. 

Upon detecting a location area change, the mobile 
station transmits a "location update request" which is re- 
ceived by the BTS of the cell in which the mobile station 
is currently to be found. This request is then passed via 
the BSC associated with the BTS, back to the relevant 
MSC. The MSC then updates the location information 
held for the mobile station in the VLR associated with 
the MSC. In the event that a mobile station moves from 
a location area covered by one MSC to a location area 
covered by another MSC, a changeover process is ef- 
fected between MSCs which also involves the HLR be- 
ing updated with the address of the MSC into whose ar- 
ea the mobile station has now moved. 

A mobile station is also arranged to send out a lo- 
cation update request message, if it receives an indica- 
tion from the network that it is not known to the VLR in 
whose coverage area it is currently located. 

Finally, in order to ensure that up-to-date location 
information is maintained on mobile stations, and also 
to enable the databases in the HLR and VLR to be rebuilt 
in case of data loss, each mobile station is arranged to 
send a location update request message (a "periodic" 
location update request) if it has not sent such a request 
within a predetermined, network configurable, amount 
of time. 

It should be noted that a mobile station will only gen- 
erate a location update request from its idle mode and 
not when it is already in its dedicated mode. Whenever 
a location update request is generated and sent then, 
regardless of ihe reason for the request, the VLR will 



respond either with a Location Update Accept or Loca- 
tion Update Reject message, as appropriate. 

User Identity - IMSI and TMSI 



Within the international GSM community, each sub- 
scriber is uniquely identified by a number, the IMSI (In- 
ternational Mobile Subscriber Identity). This number is 
fifteen digits or less and as shown in Figure 3A compris- 
io es a 3-digit mobile country code (MCC), a 2-digit mobile 
network code (MNC) giving a subscriber's home PLMN, 
and a mobile subscriber identification number (MSfN) 
identifying the subscriber in his home PLMN. The IMSI 
is not the telephone number of the subscriber - many 
is telephone numbers can be assigned to a single sub- 
scriber. 

The I MSI of a subscriber is held in a subscriber iden- 
tity module (SIM) that plugs into a mobile station. Each 
time the mobile station accesses the PLMN, the IMSI 
20 held in the associated SIM is provided to the PLMN (ei- 
ther directly, or indirectly in the form of a TMSI as will be 
explained below). The IMSI allows the PLMN to access 
the HLR where the subscriber is registered to retrieve 
subscriber-specific data and to record the MSC in 
25 whose area the mobile station is currently located, ac- 
cording to context. 

Sending the IMSI over the inherently insecure radio 
path at each PLMN access is undesirable for confiden- 
tiality and security reasons. Accordingly a temporary 
30 identity number known as Temporary Mobile Subscriber 
Identity (TMSI) is generally used as an alias for the IMSI. 
The TMSI is a four octet code allocated by the PLMN 
on a location area basis and, at any given time, unam- 
biguously identifies the subscriber in the location area 
35 concerned. When the mobile station changes location 
area, the TMSI is generally also changed. A TMSI is only 
unique within a location area and needs to be combined 
with the LAI (location area identity) of the relevant loca- 
tion area to provide a PLMN-unique identifier (see Fig- 
40 ure 3B). However, a TMSI is generally used in a context 
where the location area concerned is either already 
known or implied. 

TMSIs are managed by the current MSC / VLR. For 
a given location area, a TMSI is allocated to a mobile 
45 station when it registers in the location area; this TMSI 
is released when the mobile station leaves the location 
area. A TMSI can be allocated either by a dedicated TM- 
SI Reallocation Command passed Trom the MSC / VLR 
to the mobile station (and acknowledged by a TMSI Re- 
s ° allocation Complete message) or as part of a Location 
Update Accept message following on from the mobile 
station making a Location Update Request upon enter- 
ing a now location aroa. TMSI cancellation is usually im- 
plicit; in particular, for the mobile station, allocation of a 
5s new TMSI cancels any previously allocated TMSI as 
does receipt of a Location Update Accept message in a 
new location area. 

When a mobile station changes location area, the 
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new TMSI may be completely different from the TMSI 
used in the previous location area, or it may be the same 
(the associated LAIs then providing differentiation). It is 
also possible to explicitly cancel an existing TMSI by 
sending the TMSI Reallocation Command using the IM- 5 
SI; in this case, the mobile station reverts to using the 
IMSI to identify itself to the PLMN until next it is allocated 
a TMSI. 

Clearly, where a mobile station first identifies itself 
using an IMSI and the corresponding MSC/VLR pro- 
ceeds to allocate a TMSI . that MSC/VLR knows the IMSI 
and can therefore access the subscriber's HLR. How- 
ever, if the mobile station moves to a new location area 
covered by a different MSC/VLR, this latter will be pre- 
sented with a TMSI that does not contain sufficient in- 
formation tor the MSC / VLR to access the subscriber's 
HLR. The new MSC/VLR could make a specific Identify 
request to the mobile station to have it return its IMSI; 
however, this compromises the sought-after security. In- 
stead, therefore, the new MSC/VLR generally asks the 
old MSC/VLR for the IMSI. this being possible because 
when the mobile station sends the TMSI to the new 
MSC/VLR it also sends the LAI of the old location area 
which enables the old MSC/VLR to be identified. 

When a TMSf has been allocated and not cancelled, 
it is retained by the mobile station even when turned off. 

Tracking Subscriber Identity 

A mobile subscriber's identity is notified to the 
PLMN by the mobile station being used by the subscrib- 
er, whenever the mobile station seeks to establish a con- 
nection, that is, in the following circumstances: 

« CM service request (subscriber initiated service re- 
quest) 

Paging response (mobile station response to a pag- 
ing message) 

Location updating (notification of a new location ar- 
ea by mobile or periodic update) 
« I MSI Attach and Detach (on switch on and off of mo- 
bile station) 

-- CM re-establishment request (following loss of con- 
nection) 

The subscriber identity given by the mobile station will, 
of course, be the current TMSI (the current LAI being 
also sent) or, if none exists, the IMSI; this subscriber 
identity is referred to below as the operative subscriber 
identity. The mobile station may also supply the IMSI in 
response to an Identity request from the PLMN (the 
identity request may also be used to get the current TM- 
SI). 

When subscriber identity is being considered on a 
PLMN-wide basis, it will be appreciated that for an op- 
erative subscriber identity comprising a TMSI, the rele- 
vant LAI explicitly or implicitly forms part of the operative 
subscriber identity; however, where subscriber identity 
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is only being considered within a particular location ar- 
ea, the LAI is not needed. 

The operative subsenber identity is changed by the 
PLMN either by the TMSI Reallocation command or as 
part of a Location Update Accept message, as already 
discussed. 

Keeping track of the operative subscriber identity 
for a particular subscriber as identified by an IMSI is an 
inherent operation of the PLMN infrastructure, this map- 
ping being maintained by the MSC/VLR in which the 
subscriber is currently registered. In theory, this enables 
the behavioural characteristics of a particular subscriber 
to be monitored. However, as a practical matter, access- 
ing the information in the MSC/VLR for non-standard 
purposes requires substantial modification to existing 
software with the consequent need to re-qualify the soft- 
ware and associated systems. It is therefore attractive 
to be able to track the current operative subscriber iden- 
tity of a particular subscriber using a separate monitor- 
ing system that does not rely on the main PLMN infra- 
structure components but can perform the required 
tracking by monitoring signalling traffic in the PLMN. 

Unfortunately, the messages from the PLMN to the 
mobile station instructing it to change the operative sub- 
scriber identity to a given value, do not include the old 
subscriber identity so that simply identifying such mes- 
sages is of little value. 

According to the present invention, a message pa- 
rameter common to both the connection establishment 
messages and to messages changing the operative 
subscriber identity is used to establish a link between 
these messages thereby enabling changes in the oper- 
ative subscriber identity to be mapped. 

In a first embodiment of the present invention, sig- 
nalling messages on the A interface are monitored and 
the sought-after linkage between connection-establish- 
ment messages that include the current operative sub- 
scriber identity, and subsequent messages that change 
the operative subscriber identity, is provided by the fact 
that these messages will be passed between a BSC and 
the corresponding MSC by a connection-oriented pro- 
tocol, namely the SS7 SCCP protocol in class 2 mode. 
More particularly, the initial connection-establishment 
message passed from the BSC to MSC initiates the set 
up of an SCCP connection and in doing so passes the 
MSC a local reference that the MSC must use in subse- 
quent communications with the BSC for the transaction 
to which the connection establishment relates. In reply- 
ing to the initial message from the BSC, the MSC uses 
the BSC local reference as the destination local refer- 
ence for the reply and includes its own local reference 
as the source local reference of the reply. In subsequent 
communications for the transaction, the BSC uses the 
MSC's local reference as the destination local reference 
for its messages to the MSC. By noting these local ref- 
erences, it is possible to identify all messages relating 
to the same SCCP connection thereby enabling mes- 
sages changing the operative subscriber identity to be 
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linked to the initial connection establishment messages. 
The association of local references with a particular SC- 
CP connection only lasts for the duration of that connec- 
tion. 

In a similar manner, according to a second embod- s 
iment of the invention, signalling messages on the Abis 
interface are monitored and the channel number param- 
eter in these messages is used to provide the linkage 
between connection-establishment messages that in- 
clude the current operative subscriber identity and sub- io 
sequent messages that change the operative subscrib- 
er identity. As the channel number may be changed dur- 
ing a transaction (to change from an initial signalling 
channel to a traffic channel), it is necessary also track 
such channel number changes. is 



First Embodiment-Detailed Signalling Example 

By way of example of the general manner of oper- 
ation of the first embodiment, consider the case where 20 
a mobile station in idle mode determines that it is in a 
new location area. This results in the mobile station 
making a Location Update Request with the current op- 
erative subscriber identity; if all is well, the PLMN will 
respond with a Location Update Accept including a new 2s 
TMSI to be used as the operative subscriber identity. 

More particularly, and with reference to Figure 4, the 
mobile station first transmits a Channel Request on the 
RACH channel which is picked up by a BTS and passed 
as a Channel Required message to the associated BSC 30 
(line ('a'), Figure 4). The BSC responds by choosing a 
free channel and activates it in the BTS (this activation 
and the acknowledgement from the BTS to the BSC are 
not depicted in Figure 4). Thereafter, the BSC initiates 
the sending of an Immediate Assignment message on 35 
the PAG CH channel telling the mobile station the details 
of the channel it has been allocated for further signalling 
communication (line b). 

The mobile station then sets its reception and trans- 
mission configuration to the assigned channel and es- 40 
tablishes a link-level connection with the BTS on the 
new channel by sending a SABM frame; this SABM 
frame also carries the initial message which in the 
present example includes the Location Update Request 
and the operative subscriber identity. The Location Up- 45 
date Request is then passed from the BTS to BSC in an 
Establish Indication message. The BSC on receipt of 
this message sets up an SCCP connection with the cor- 
responding MSC by means of a Connection Request 
message onto which the Location Update Request is so 
generally piggybacked (line (c) in Figure 4). 

The format of this first message from the BSC to 
MSC is illustrated in Figure 5. As for all messages on 
the *A' interface, the SS7 SCCP (Signalling Connection 
Control Part) and underlying MTP (Message Transfer ss 
Part) provide the transport service. More particularly, in- 
formation is transported in MTP level 2 signalling units, 
the composition of which is a Flag field, a Backward Se- 



quence Number BSN field, a Backward-Indicator bit 
BIB. a Forward Sequence Number FSN field, a For- 
ward-Indicator bit FIB. a Length Indicator LI, a Spare SP 
field, a Service Information Octet SIO, a Signalling In- 
formation Field SIF, a Check field, and a terminating 
Flag field. MTP level 3 information is contained in the 
SIO and in a routing label forming part of the level 2 sig- 
nalling information field. The routing label includes 
source and destination addresses for the signalling unit 
in terms of point codes. Above MTP level 3 is the SCCP 
layer for carrying information according to a required 
service type (in this case, connection-oriented). An SC- 
CP header includes further addressing information that, 
inter alia, specifies what is termed a "subsystem 
number" for identifying the user of the transport service 
provided by the SCCP In the present case, the user is 
the Base Station Subsystem Application Part (BSSAP) 
peer-to-peer protocol operating between the BSS and 
MSC concerned. BSSAP messages are identified by a 
subsystem number or "FE" in hex. The SCCP header 
also normally includes both the afore-mentioned source 
and destination local references for the connection con- 
cerned though, of course, for the present Connection 
Request message only the source local reference (for 
the BSC) will bo present as this message is the initial 
message for the connection. 

BSSAP is sub-divided into two parts, each BSSAP 
message being associated with one or other part as in- 
dicated by a discriminator octet (DSCR in Figure 5). 
These two parts are a BSS Management Application 
sub-part (BSSMAP) which is used for radio resource 
(RR) and BSC management; and a Direct Transfer Ap- 
plication sub-part (DTAP) which is used for the transfer 
of call control management (CM) and mobility manage- 
ment (MM) messages. Location update requests are re- 
lated to mobility management and it might therefore be 
expected to find such requests embedded in DTAP mes- 
sages. In fact, location update requests are embedded 
in BSSMAP messages. The reason for this is that each 
location update request requires the establishment of a 
new radio connection between the mobile station con- 
cerned and the relevant MSC, and the establishment of 
such a connection is a radio resource management is- 
sue. Indeed, whenever a new radio connection is estab- 
lished, the "initial message" concerned with that con- 
nection is piggy-backed onto the RR message on the 'A' 
interface involved in setting up the connection through 
to the relevant MSC. Initial messages, including Loca- 
tion Update Requests, are carried in BSSMAP "Com- 
plete Layer 3 Information" messages, these latter being 
indicated by a message type octet '0101011V (the right- 
most bit being the first bit of the octet). Each "Complete 
Layer 3 Information" message comprises two informa- 
tion elements, namely Cell Identifier and Layer 3 Infor- 
mation. It is the "Layer 3 Information* information ele- 
ment that actually contains the Location Update Re- 
quest as well as the operative subscriber identity (for a 
TMSI, the old location area identifier LAI, which is an 
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element of the current TMSt. can also be found in this 
information element). The "Cell Identifier" information 
element includes the current location area of the mobile 
station. 

According to the first embodiment of the present in- 
vention a monitor probe monitoring the BSC/MSC link 
is arranged to detect all initial messages such as that 
illustrated in Figure Sand extract the operative subscrib- 
er identity from the Layer 3 Information element as well 
as the SCC P local reference of the BSC. This local ref- 
erence is subsequently used by the monitor probe to 
identify all messages relating to the same SCCP con- 
nection until the latter is taken down. 

Returning now to Figure 4, following receipt of the 
Location Update Request by the MSC, authentication 
and ciphering messages may, optionally, be exchanged 
between the mobile station and the MSC (lines (d) to 
(g)). The probe monitoring the relevant BSC/MSC link 
knows trom the source local reference or destination lo- 
cal reference (depending on message direction) that 
these messages relate to the SCCP connection associ- 
ated with the location update transaction but by moni- 
toring the message types, the probe determines that the 
messages do not concern modification of subscriber 
identity. 

In due course, the MSC sends a Location Update 
Accept message which, in the present example, also 
sets a new TMSI (line (h) in Figure 4). This message is 
detected by the monitor probe as associated with the 
SCCP connection of interest and this allows the new 
TMSI to be linked with the old operative subscriber iden- 
tity, providing the sought-after mapping. The Location 
Update Accept message, being a mobility management 
message (which is not alsoan initial message) is carried 
in a DTAP message on the A interface. 

Upon receipt of the Location Update Accept mes- 
sage including the new TMSI, the mobile station returns 
a TMSI Reallocation Complete message (line (i) in Fig- 
ure 4); this message is also carried in a DTAP message 
on the A interface. Finally, the MSC sends a Clear com- 
mand in a BSSMAP message piggybacked on an SCCP 
Release message. The BSC passes on the Release 
Command as a Channel Release message (line (j) in 
Figure 4), thereafter sending back a Clear Complete 
message to the MSC in a BSSMAP message piggy- 
backed on an SCCP Release Complete message. This 
release complete message and subsequent release 
messages between the mobile station, BTS and BSC 
are not shown in Figure 4. The monitor probe on the A 
interface detects the SCCP connection release mes- 
sages and cancels its record of the SCCP connection. 

Figures 6 and 7 are further examples simitar to Fig- 
ure 4 showing tho mapping between a subscriber iden- 
tity operative at the time of connection establishment, 
and a subsequently-assigned TMSI, the linkage be- 
tween the relevant messages being established through 
the local references of the SCCP connections con- 
cerned. Figure 6 relates to a subscriber-initiated service 
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request and Figure 7 relates to a paging-initiated re- 
sponse from the mobile station. In both cases, the MSC 
sends a TMSI Reallocation Command which the mobile 
station acknowledges in a TMSI Reallocation Complete 
s message; both messages are carried in DTAP messag- 
es on the A interface. 

First Embodiment - Basic Implementation 

io As illustrated in Figure 1 . each 'A' interface is mon- 
itored by a respective monitor probe 40. These monitor 
probes 40 extract subscriber identity information from 
the messages on the 'A' interface and pass this infor- 
mation in report messages back to a central station 42 

is where further processing is carried out. Communication 
between the monitor probes 40 and the central station 
42 is effected over a network 41 that may be a dedicated 
network or an existing one such as the operations and 
management network associated with the main net- 

20 work. 

Figure 8 illustrates the general operation of a mon- 
itor probe 40. On receipt of a message, the probe 40 
decodes the message to determine its type (step 50). If 
the message is an "initial message" concerning connec- 
ts tion establishment, the probe 40 creates a connection 
record 51 for the SCCP connection being set up and 
stores in this record the following elements (step 52): 

- the location area of the cell in which the mobile sta- 
30 tion is currently located, this information being ex- 
tracted from the Cell Identifier information element 
of the monitored initial message (in certain cases, 
this information may not be present); 

- the operative subscriber identity (IMSI, or TMSI plus 
35 the LAI of the location area in which the TMSI was 

allocated) given in the Layer 3 Information informa- 
tion element of the monitored initial message; and 

- the BSC local reference for the SCCP connection. 

.40 if the monitored message is a Release Command, 
the probe 51 uses the destination local reference to 
identify and cancel the corresponding connection record 
51 (step 53). 

Where the monitored message changes the opera- 
45 live subscriber identity (a TMSI Reallocation command 
or a Location Update Accept message) or gives the true 
subscriber identity (in a Identity Response message), 
the monitor probe 40 first determines the corresponding 
connection record from the appropriate SCCP local ref- 
50 erence and then generates a report message 54 to re- 
port the new information on subscriber identity to the 
central station 42 (step 55). This report message 54 
comprises a probe ID field 56 identifying the probe, a 
field 57 containing the current location area LAI as held 
55 in the corresponding connection record 51, a field 58 
holding the old operative subscriber identity as held in 
the connection record 51 , a field 59 containing the newly 
detected subscriber-identity information, and a report 
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type 60 indicating whether the report message concerns 
an identity change or is reporting an identity response 
message. In the case of an identity change, the field 59 
will contain the new operative subscriber identity (either 
the I MSI, or more probably, a new TMSI and the current 
LAI). In the case of an Identity Response message con- 
taining an I MSI, the field 59 contains the I MSI (in fact, if 
the operative subscriber identity is also the subscriber 
I MSI, no report message is generated). Each of the 
fields 58, 59 will typically be compound, comprising both 
an indicator of identity type (IMSI or TMSI+LAI) as well 
as the identity itself (even without such a type indicator, 
it would be possible to distinguish between the two iden- 
tity types by their length but it is more convenient to use 
an indicator). 

With regard to the identity change messages, the 
output of the report message is preferably deferred until 
a TMSI Reallocation Complete message acknowledg- 
ing the change is detected by the probe 40 for the rele- 
vant SCCP connection. 

As well generating the report message 54, in step 
55 monitor also updates the relevant report record with 
any pertinent newly-detected information. Thus, if the 
operative subscriber identity has been changed, this 
now operative identity is stored in the connection record 
in place of the previously-stored operative subscriber 
identity. Furthermore, where a Location Update Accept 
message or TMSI Reallocation command is being proc- 
essed by the monitor 40, since both these message 
types include the current location area identity, the mon- 
itor 40 also takes the opportunity to update the connec- 
tion record 51 with this information, replacing the previ- 
ous entry. 

For message types other than those discussed 
above, the monitor probe 40 need take no action in re- 
spect of subscriber identity tracking (except in relation 
to handovers, as discussed in the following section). 
However, as it may be useful to keep track of the current 
location area of a mobile station, provision can also be 
made for reporting changes in location area that are not 
associated with a change in subscriber identity (this can 
occur if the IMSI is being used in both the old and new 
location areas). More particularly, if a Location Update 
Request is detected followed by a Location Update Ac- 
cept not including a Reallocation command and an ex- 
plicit TMSI Reallocation command does not follow within 
a predetermined timeout period, then a report message 
51 is generated lo report the new location area of the 
mobile station in field 57; in this case, field 60 can be 
arranged to indicate that the report message is simply 
reporting a location area change. 

Turning now to a consideration of the operation of 
the central station 42, this station maintains a table 61 
(see Figure 9) which includes an entry for each known 
IMSI, IMSI(a) to IMSI(m), this entry giving by location 
area LAI(1)to LAI(N), the current operative TMSI, if any, 
corresponding to the IMSI concerned. 

On receipt of a report message 54 from any one of 



the monitor probes 40, the central station 42 classifies 
(step 62) the information it contains into one of five cas- 
es according to the contents of the field 60 and of the 
fields 58 and 59: 
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Case A - 
Case B - 

Case C - 
Case D - 
Case E - 



the operative subscriber identity has been 
changed from an IMSI to a TMSI; 
the operative subscriber identity has been 
changed from a TMSI to a new TMSI (po- 
tentially in a different location area); 
the operative subscriber identity has been 
changed from a TMSI back to the IMSI; 
the IMSI of a subscriber is being reported 
together with the current operative TMSI; 
location area has been updated without a 
change of the operative subscriber identity. 



The station 42 then proceeds to update the table 61 
(step 63) in dependence on its classification of the re- 
ported information. The update procedure Tor each case 
is as follows: 

Case A: IMSI to TMSI Change - The table 61 is first 
searched for the IMSI. If the IMSI is located, any 
existing TMSI that might bo present in the IMSI en- 
try is removed and the new TMSI is added under 
the appropriate location area. If the IMSI is not 
found, a new table entry is created for the IMSI and 
the new TMSI entered according to its location area 
Case B: TMSI to TMSI Change - The table 61 is 
first searched for the old TMSI (contained in mes- 
sage field 58), this search being facilitated by the 
organisation of the table by location area, the loca- 
tion area of the old TMSI being known. If the old 
TMSI is not found in the table, then the correspond- 
ing IMSI must still be unknown in which case no en- 
try is possible and the updating operation is termi- 
nated. Assuming, however, that the old TMSI is 
found, the new TMSI is inserted into the same I MSI 
entry under the appropriate location area and the 
old TMSI is removed. 

Case C: TMSI to IMSI Change - The IMSI is first 
searched for in table 61 , and if found, any TMSI en- 
tered in the IMSI entry is removed. If the IMSI is not 
found in the table, a new IMSI entry is added without 
any TMSI (a 'no TMSI' indication can optionally be 
added under the appropriate location area in which 
event in Case A this indication would need remov- 
ing when a TMSI was allocated). 
Case D: IMSI and Operative TMSI reported - This 
case can be handled in the same manner as Case 
A above. 

Case E: Location Update reported - This case sim- 
ply involves the subscriber identity entry (here, gen- 
erally a "no TMSI" indication) being moved to the 
appropriate location area column of table 61 . 

By updating the table 61 in this way, the central sta- 
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tion can keep track of the current operative subscriber 
identity for all subscriber's whose IMSIs are known. Of 
course, as will be appreciated by persons skilled in the 
art, it would also be possible to arrange for changes in 
TMSI to be tracked even if the corresponding IMSI was 
not known. The table also enables the current location 
area of the subscriber to be tracked. 

First Embodiment - Dealing With Handovers 

In the foregoing, it has been assumed that each 
transaction only involves one SCCP connection - in 
practice, as a subscriber moves, the mobile station may 
pass from one cell to another and this may result in a 
change in BSC which, of course, involves the original 
SCCP connection being taken down and a new one es- 
tablished. Whilst there are well known handover proce- 
dures lor coping with changes in cell during the course 
of a communication session, changes in SCCP connec- 
tion can impact the tracking method described above. 

More particularly, it is quite likely that no messages 
will appear on the new SCCP connection to give the op- 
erative identity code whereas a TMSI reallocation mes- 
sage could be issued changing the operative identity 
code; in such a situation, the tracking method described 
above would be inadequate. What is required is some 
way of linking the old and new SCCP connections so 
that the operative identity code known for the old SCCP 
connection can be transferred across into the record es- 
tablished for the new connection. 

To achieve this, the monitor probes 40 are arranged 
to monitor hand-over related signalling on the A inter- 
faces, so as to collect common parameters that appear 
on both an old SCCP connection about to be taken down 
in respect of a communication session and on a new 
SCCP connection established to take over a communi- 
cation session; the values of these common parameters 
are then compared to match up old and new SCCP con- 
nections related to the same communication session. 

By way of example, consider the case of a handover 
between one BSC, hereinafter "BSCold", and another 
BSC, hereinafter "BSCnew", connected to the same 
MSC (as will become apparent, the method to be de- 
scribed for correlating old and new SCCP connections 
relating to the same communication session across a 
hand-over, applies equally to the case where the MSC 
also changes). Figure 10 illustrates the A-interface links 
involved in the hand-over, the related signalling connec- 
tions between the BSCs and the mobile station being 
omitted for clarity. More particularly, mobile station 12 
initially communicates with MSC 20 via BSCold 17A us- 
ing an SCCP connection "SCCPold" established across 
A-intcrfacc link 68 by an initial message 70; after hand- 
over, the mobile station communicates with MSC 20 via 
BSCnew 172 using an SCCP connection "SCCPnew" 
established across A-interface link 69 by a handover re- 
quest message 72. Links 68 and 69 are monitored by 
respective monitor probes 40A and 402, these probes 
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being operative to detect hand-over related messages 
and to relate them, using the SCCP local references, to 
the connection records 51 established for the SCCP 
connections concerned. 

5 Figure 1 0 shows the message flows seen on SC- 

CPold and SCCPnew during the course of a successful 
hand-over. It is BSCold 1 7 A that makes the decision that 
a hand-over is required, this decision being based on 
information it receives from the mobile station. On de- 

io ciding that a handover is required, BSCold 17A sends 
a BSSMAP Handover Required message 71 to the MSC 
20. MSC 20 is responsible for making the decision to 
effect a handover and if it makes a positive decision, it 
opens SCCPnew to BSCnew 1 72 and sends a BSSMAP 

15 Handover Request message 72 to BSCnew 1 7Z. BSC- 
new, after allocating a radio channel for the mobile sta- 
tion, answers with a BSSMAP Handover Request Ac- 
knowledge message 73 that contains a RR3 Handover 
Command signalling unit; this is the piece of information 

20 that will ultimately gel passed to the mobile station to 
tell it, in terms of radio frequencies and timeslot number, 
where it is supposed to tune to. 

On receiving the BSSMAP Handover Request Ac- 
knowledge message, MSC 20 puts the RR3 Handover 

25 Command into a BSSMAP Handover Command 74 
which it sends over SCCPold to BSCold 17A; BSCold 
17A forwards this message to the mobile station 12. 

The mobile station then establishes contact with 
BSCnew 17Z using the radio channel allocated by the 

30 tatter. Upon contact being successfully established. 
BSCnew sends a BSSMAP Handover Complete mes- 
sage 75 on SCCPnew to MSC 20 which then sends a 
BSSMAP Clear command 76 on SCCPold to BSCold 
17A, this command including a 'handover successful* in- 

35 dication. SCCPold is thereupon terminated. 

From the foregoing, it will be seen that the RR3 
Handover Command signalling unit appears both on 
SCCPnew and SCCPold. Matching the parameter val- 
ues of this signalling unit forms the basis of correlating 

40 SCCPnew and SCCPold. In fact, it is conceivable that 
two hand-overs could occur in a PLMN at substantially 
the same moment with the same RR3 Handover Com- 
mand parameter values, in which case solely relying on 
these parameter values to effect SCCP connection cor- 

45 relation, whilst generally producing satisfactory results, 
will occasionally lead to ambiguity and possible errors 
(or at least inability to make a correlation). It is therefore 
preferred to effect correlation on the basis of both RR3 
Handover Command parameters values and the cell ID 

50 of the cell from which the hand-over is being effected 
('old celllD"); including this additional parameter in the 
match criteria makes it highly unlikely (though, in theory, 
not impossible) that an ambiguity will occur. The old Cel- 
llD appears on SCCPold in the initial massage 70 setting 

ss up SCCPold (if a BSC-internal handover subsequently 
occurs changing the operative cell without changing the 
SCCP connection, then the cell ID of the new cell is the 
one that must be used as the "old CelllD' for correlating 
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SCCP connections should a subsequent handover in- 
volve a change in BSC - this new "old CelllD" can be 
ascertained from the BSSMAP handover Performed 
message, not illustrated, which a BSC will send to the 
associated MSC in the case of a BSC-intemal hando- 5 
ver). The old CelllD appears on SCCPnew in the BSS- 
MAP Handover Request message 72. 

The process of correlating SCCPold and SCCPnew 
thus proceeds as follows: Monitor 40A monitoring link 
68: 10 

(i) - when a new SCCP connection is set up by an 
initial message, the monitor 40A creates a new con- 
nection record 51, extracts the old CelllD from the 
initial message, and associates it with the newly- is 
created connection record; 

(ii) - upon a BSSMAP Handover Performed mes- 
sage (not shown) being detected by monitor 40A, it 
extracts the new cell ID and substitutes it for the old 
CelllD associated with the conneclion record iden- 20 
tified by the SCCP local references of the BSSMAP 
Handover Performed message 71 ; 

(iii) - When the monitor 40A detects a BSSMAP 
Handover Command 74, it extracts the RR3 Hando- 
ver Command parameter values and associates 25 
them with the relevant connection record (again, 
identified by the SCCP local references of the com- 
mand 74), 

(iv) - Upon the monitor 40 A detecting a BSSMAP 
Clear Command 76, if the connection record 51 30 
identified from the SCCP local references of the 
command 76 already has old CelllD and RR3 
Handover Command parameter values associated 
with it, the monitor 40 A sends a Correlation Old 
message 80 to Ihe central station 42 including the 35 
monitor ID, the old CelllD. the parameter values of 

the RR3 Handover Command, and the current op- 
eration subscriber identity as held in the connection 
record 51 . The connection record is then removed. 

40 

Monitor 40Z monitoring link 69: 

(i) - upon the MSC setting up SCCPnew, monitor 
40Z creates a corresponding connection record 51 
including at least one of the SCCP local references 4S 
(if only the BSC local reference is stored as in the 
embodiment previously described, then this refer- 
ence is taken from the BSCnew reply to the initial 
Connection set up message from the MSC). 

(ii) - when a BSSMAP Handover Request message so 
72 is detected by monitor 40Z, it extracts the old 
CelllD and associates it with the connection record 
identified by the appropriate SCCP local reference 

of the message 72; 

(iii) - upon the monitor 40Z detecting a BSSMAP ss 
Handover Request Acknowledgement 73, it ex- 
tracts the RR3 Handover Command parameter val- 
ues and associates them with the record identified 



by the appropriate SCCP local reference of the 
message 73; 

(iv) - when a Handover Complete message 75 is 
detected by monitor 40Z, it checks whether the con- 
nection record identified by the appropriate SCCP 
local reference of the message 75 has associated 
old CelllD and RR3 Handover Command parameter 
values - if these parameter values are present, the 
monitor 40Z sends a Correlation New message 81 
to the central station 42 including the monitor ID, 
the old CelllD, the parameter values of the RR3 
Handover Command, and the SCCP local refer- 
ence used to identify the connection record, 
(v) - where the central station 42 is able to correlate 
an SCCPold with an SCCPnew monitored by mon- 
itor 40Z (see below regarding how this is done), the 
monitor 40Z receives in due course a Correlation 
Complete message 82 that contains the SCCPnew 
connection and the operative subscriber identity 
from the corresponding SCCPold connection. The 
monitor 40Z uses the SCCP local reference in mes- 
sage 82 to locate the corresponding connection 
record 51 and then inserts the operative subscriber 
identity into the record. 

Central Station 42 

(i) - Station 42 maintains two correlation tables, 
these being an Old correlation table 85A each entry 
of which holds the contents of a corresponding Cor- 
relation Old message 80. and a New correlation ta- 
ble 85Z each entry of which holds the contents of a 
corresponding Correlation New message 81 . Each 
entry in tables 85A and 85Z has an associated 
timestamp corresponding to the time of entry crea- 
tion. 

(ii) - When a Correlation Old message 80 is re- 
ceived, the station 42 checks the New correlation 
table 85Z for any entry having the same values of 
old CelllD and RR3 Handover Command parameter 
values. If no match is found, the contents of the Cor- 
relation Old message 80 are entered in table B5A. 
However, if a match is found, a Correlation Com- 
plete message 82 is generated and sent to the mon- 
itor 40Z identified in the entry held in table 85Z; this 
entry is thereafter cancelled. 

(iii) - When a Correlation New message 81 is re- 
ceived, the station 42 checks the Old correlation ta- 
ble 85A for any entry having the same values of old 
CelllD and RR3 Handover Command parameter 
values. If no match is found, the contents of the Cor- 
relation New message 81 are entered in table 85Z. 
However if a match is found, a Correlation Com- 
plete message 82 is generated and sent to the mon- 
itor 40Z identified in the Correlation New message 
81; the relevant entry in the Old table 85 A is then 
cancelled. 

(iv) - Periodically, the tables 85A and 85Z are 
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scanned and any entries older than a predeter- 
mined threshold, as judged from their timestamps, 
are deleted. This predetermined threshold is set by 
the maximum delay likely to occur between related 
correlation messages 80 and 81 . In this way, any 
unmatched table entries are periodically removed. 

The handover operation may, of course, fail for a 
number of different reasons and the monitors 40 need 
to be able to detect and handle such situations (gener- 
ally- station 42 will be unaware of attempted handovers 
that fail) Thus, if BSCnew 172 returns a BSSMAP 
Handover Failure message instead of a BSSMAP 
Handover Request Acknowledge 73, monitor 40Z on 
detecting this message is arranged to remove its corre- 
sponding connection record 51 , whilst monitor 40A is 
arranged tocanccl the old CelllD information associated 
with its connection record 51 for the relevant SCCPold 
connection 

Aflcr the BSSMAP Handover Command 74 has 
been passed to BSCold 17A, handover failure may oc- 
cur for any o( the lollowing reasons: 

(a) The mobile station 1 2 is unable to establish con- 
tact with BSCncwand reverts to the old radio chan- 
nel. In this case, a BSSMAP Handover Failure will 
be passed from BSCold 17A to MSC 20 on SC- 
CPold enabling monitor 40A to cancel the handover 
parameters associated with the corresponding con- 
nection record The MSC then issues a BSSMAP 
Clear Command to BSCnew 1 72 on SCCPnew; the 
monitor 40Z detects this command and thereupon 
removes the corresponding connection record. 

(b) The mobile station 1 2 fails to establish contact 
with BSCnew but does not revert to the old radio 
channel. In this case, a BSSMAP Clear Request is 
passed from BSCold 17A to MSC 20 on SCCPold 
in response to which MSC sends a BSSMAP Clear 
Command to both BSCold and BSCnew. Monitors 
40A and 402 detect the clear command and remove 
their corresponding connection records. 

(c) The MSC decides to abort the handover proce- 
dure and sends a BSSMAP Clear Command to both 
BSCold and BSCnew on SCCPold and SCCPnew 
respectively. The monitors 40A and 402 detect this 
command and remove their corresponding connec- 
tion records. 

The Clear Commands issued in the above cases will in- 
clude cause codes enabling the various cases to be dis- 
tinguished from one another. 

It will be appreciated that the foregoing method of 
correlating SCCPold and SCCPnew docs not rely on 
MSC 20 being the switching point for the handover so 
that switching could instead occur at an anchor MSC 
(the primary MSC involved in setting up a particular call 
- this MSC does not change throughout the call). 

It may be noted that in the embodiment described 



above, tracking the SCCP connection across a hando- 
ver does not alter the manner in which subscriber iden- 
tity change reports are made by the monitors 40A and 
402 nor how such messages are handled at the central 

s station 42. 

Finally, it may also be noted that since the current 
location area of the mobile station is contained in the 
BSSMAP Handover Request message 72, this informa- 
tion can readily be extracted by monitor 402 and insert- 

10 ed in the connection record 51 associated with SCCP- 
new. Because it is conceivable that the location area 
may be changed by the handover at the same time as 
the operative subscriber identity is left unchanged 
(where it is the IMSI and therefore valid in all location 

15 areas), monitor 40Z is arranged to generate a report 
message 54 of the location update type if it detects no 
TMSI Reallocation command within a predetermined 
period following the handover being successfully com- 
pleted; this message may well be redundant but this will 

20 not cause any problems at the central station 42. 

Second Embodiment 

As already noted, the second embodiment of the 
25 present invention operates in a similar manner to the 
first embodiment but monitors messages on the Abis in- 
terface rather than the A interface and uses the channel 
number parameter to link messages relating to the same 
transaction. The channel number parameter identifies 
30 the channel type, TDMA offset and time slot number of 
the radio channel to be used on the air interface; the 
channel number parameter appears in certain messag- 
es on the Abis interface, either in a Channel Number 
information element or as part of a Channel Description 
35 information element. 

By way of example of the operation of the second 
embodiment, consider again the location update trans- 
action depicted in Figure 4. The Location Update Re- 
quest (line c) is carried on the Abis interface in an Es- 
•to tablish Indication message that includes the Channel 
Number information element identifying the signalling 
channel previously assigned by the BSC concerned for 
handling the location update procedure. A monitor 
probe on the Abis interface detects this Establish Indi- 
es cation message, creates a record for the channel 
number concerned, and enters the operative subscriber 
identity contained in the Establish Indication message 
into the record. In due course, Ihe same monitor probe 
detects a Location Update Accept (line h) for the same 
50 channel number, both the Location Update Accept and 
channel number being carried in information elements 
of a Data Request message. As a result, the monitor 
probe sends a report message back to a central station. 
The monitor probe also updates its record for the chan- 
55 nel by recording the new operative subscriber identity 
contained in the Location Update Accept. In fact, as al- 
ready indicated for the first embodiment, the sending of 
the report message and record updating may be de- 
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layed until after the corresponding TMSI Reallocation 
Complete message is detected, carried in a Data Indi- 
cation message on the Abis interface. Finally, at the end 
of the location updating transaction, a Channel Release 
message is sent from the BTS to the mobile station; this 
release message is detected by the monitor probe which 
thereupon cancels the record it was maintaining for the 
channel concerned. 

From the foregoing it can be seen that in respect of 
subscriber identity tracking, the general operation of the 
monitor probe, the form of the report message, and the 
operation of the central station can be substantially the 
same for the second embodiment as the corresponding 
components of the first embodiment. Accordingly, these 
components will not be described in detail for the second 
embodiment, it being apparent to a person skilled in the 
art what variations are necessary to adapt them to the 
specifics of the Abis interface. 

The foregoing review of the second embodiment did 
not consider what happens in the case of a handover. 
However, before describing how handover is dealt with, 
another complication, this time specific to the second 
embodiment, will be mentioned. This complication is 
that even without a cell change, the allocated channel 
will bo changed in the case whore it is necessary to as- 
sign a traffic channel following initial allocation of a sig- 
nalling channel. This change will of course result in a 
new channel number being assigned. Tracking of chan- 
nel number changes can be effected by looking for an 
Assignment Command message passed from the BSC 
to the mobile station, this command being sent on the 
old channel and including details of the new channel to 
be used in a Channel Description information element. 
When a monitor probe detects the Assignment Com- 
mand it modifies the record it is maintaining for the old 
channel number by changing the channel number to the 
new one. 

Consideration will now be given as to how the sec- 
ond embodiment follows a procedure (transaction) 
across a handover. Figure 11 illustrates the main mes- 
sages exchanged with a BSC 17 when a mobile station 
12 is handed over from one BTS (BTSold 13A) to an- 
other (BTSnew 1BZ} connected to the same BSC 17. 
The Abis interface between BTSold 18A and BSC 17 is 
monitored by monitor probe 140A whilst the interface 
between BTSnew 1 8Z and BSC 1 7 is monitored by mon- 
itor probe 1402. 

BSC 17 makes its decision regarding handover 
based on radio signal measurements received from BT- 
Sold 18A in a Measurement Result message 91, this 
message indicating the channel to which it relates by 
the inclusion of the channel number of the mobile/BT- 
Sold channel. Upon deciding to initiate handover, BTS 
17 sends a Channel Activation message 92 to the BT- 
Snew 182 and receives a Channel Activation Acknowl- 
edgement message 93 in return. The Channel Activa- 
tion message contains the channel number of the chan- 
nel to be used by BTSnew 18Z as well as a Handover 



Reference number; monitor 140Z on detecting the 
Channel Activation message, creates a new record 1 51 
for the channel number identified in the message and 
associates the Handover Reference number of the mes- 
5 sage with that record 151. 

After receiving the Channel Activation Acknowl- 
edgement message 93, BSC 17 sends a Handover 
Command 94 to BTSold 18A, The Handover Command 
message includes, of course, the channel number for 
io the existing channel between BTSold and the mobile 
station. In addition, the Handover Command contains a 
Channel Description information element with the chan- 
nel number of the channel to be used by BTSnew 18Z, 
and the Handover Reference number; both the channel 
75 number for BTSnew and the Handover Reference are 
extracted by monitor probe 140A and associated with 
the record 151 previously-established for the current 
channel between BTSold and the mobile station 12. 
In due course, the mobile station changes to BT- 
20 Snew and the latter sends a Handover Complete mes- 
sage 95 to BSC 17. On detecting this message, the 
monitor probe 1 40Z sends a Correlation New message 
181 to central station 142 containing the channel 
number for BTSnew and the Handover Reference 
2B number. When the BSC receives the Handover Com- 
plete message it sends a Channel Release message 96 
to BTSold. Monitor 140A detects this message and 
thereupon sends a Correlation Old message 1 80 to cen- 
tral station 142; this message contains not only the 
30 channel number for BTSnew and the Handover Refer- 
ence number, but also the current operative subscriber 
identity. Central station 142 then uses the Correlation 
Old and Correlation New messages to associate the 
new channel with the old one and thereupon pass the 
3$ operative subscriber identity to monitor 1 40Z for adding 
to the relevant record 151. The operation of station 142 
is substantially the same as station 42 of Figure 10; in 
particular, a timestamping mechanism is used to ensure 
that only the most recent Correlation Old and Correla- 
te tion New messages are retained for matching thereby 
minimising the risk of erroneous matches. 

Monitor probe 140Z thereafter monitors the Abis in- 
terface between BSC 17 and BTSnew 18Z to detect 
messages relating to the new channel and identity any 
45 changes in operative subscriber identity in the manner 
already described. 

It will be appreciated that apart from the different 
handover parameters delected by the monitors probes 
of the first and second embodiment, the monitor probes 
50 1 40A, Z operate in substantially the same manner as the 
monitor probes 40A.Z in respect of handover following. 

It will also be appreciated that the foregoing method 
of correlating the old and new channels associated with 
the same transaction does not rely on BSC 1 7 being the 
S5 switching point for the handover so that switching could 
instead occur at an MSC or anchor MSC (in other words, 
the BTSold and BTSnew need not be connected to the 
same BSC). 
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Monitoring Subscriber Behaviour 

For a subscriber whose IMSI is contained in table 
61. it is possible to monitor the behaviour of that sub- 
scriber by passing the current operative subscriber iden- 
tity (the TMSI entered for the subscriber's IMSI entry in 
table 61 or where no TMSI is present, the IMSI itself) to 
all monitor probes 40 and instructing the probes to mon- 
itor and report activity of interest. Should the operative 
subscriber identity change, then at the time the table 61 
is updated, the central station 42 notifies the probes 40 
of this new identity, the old identity to be watched being 
cancelled in the probes. 

In fact, because the table 61 identifies the current 
location area of a subscriber, it is not necessary for all 
monitor probes 40 to be instructed to watch for subscrib- 
er activity; instead, only those probes 40 in the current 
location area indicated by table 61 need to be instructed. 
In this case, when the table 61 indicates that the mobile 
station has moved lo a new location area, the walch is 
also transferred to that area by notifying the monitor 
probes in that location area, the probes 40 in the old 
location area being stood down. 

In order to facilitate the triggering of probe updating 
in relation to these watch functions, each IMSI entry in 
the table 61 can conveniently include a field indicating 
whether the corresponding subscriber is being watched. 
Whenever a table entry is updated, this field is checked 
and if this indicates that a watch is being maintained, 
appropriate probe updating is effected. 

Tracking Equipment Identity Codes 

The techniques described above may be extended 
to track identifiers of the equipment used instead of. or 
in addition to, identifiers of the subscribers using the 
equipment. 

In a mobile communications system each handset 
is allocated an equipment identity. Owing to variations 
between handset manufacturers, and variations in the 
manufacturing process within handset manufacturers, 
network operators need to identify individual handsets 
or batches of handsets which for example are not per- 
forming as expected, or as a precaution to detect fraud- 
ulent usage of multiple handsets claiming to have the 
same equipment identity. 

In the case of GSM, each handset is allocated an 
International Mobile Equipment Identity (IMEI). Thus, 
whereas the IMSI and/or TMSI identify the user of the 
handset, the IMEI identifies the handset itself. Each 
transaction between the mobile station and the network 
involves the use of an IMSI, a TMSI or an IMEI. 

In general, an IMEI can be tracked by monitoring all 
the signalling on the GSM Abis interface and noting 
when IMEIs are used. Whenever an IMEI is found, the 
rest of the transaction between the mobile statbn and 
the BTS is checked to see if either an IMSI or TMSI is 
also used. In this way the IMEI can be associated with 
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an IMSI and/or a TMSI. 

It is necessary to associate the IMEI with the cur- 
rently used IMSI and/or TMSI because the IMEI is not 
used in every transaction between the mobile station 

5 and the network. On occasions where the IMEI is not 
used in a transaction, either the currently associated IM- 
SI or TMSI can be tracked during that transaction, as 
described above, and used if required to establish the 
identity of the handset. 

10 in the case of a CM Service Request, for example, 
the mobile station initially identifies itself to the network 
using the IMSI or TMSI. The network then asks for the 
IMEI in an Identity Request. The Channel Number pa- 
rameter is used to link messages relating to the same 

is transaction, as described above in relation to the 'Sec- 
ond Embodiment'. 

The table shown in Figure 9, used to note the TMSIs 
currently associated with the currently used IMSIs, is ex- 
tended to associate each currently used IMEI with each 

20 current IMSI and any corresponding TMSI. In elfecl this 
is accomplished by adding a third dimension to the table 
of Figure 9, with different detected IMEIs being listed 
along this third dimension. The table entries are updated 
as new IMSI/TMSI/IMEI correspondences are discov- 

25 orcd and as current correspondences disappear, so that 
for each known IMSI/tMEl pairing, there is an entry giv- 
ing by location area the current operative TMSI, if any, 
corresponding to that I MSI/I ME I pairing. 

An IMSI or TMSI may be sent in a number of differ- 

30 enl Initial Layer 3 messages, depending on the proce- 
dure taking place. The procedures in the following list 
use an Initial Layer 3 message and allow Identity Re- 
quest signalling to be used within the procedure: 

in a Mobile Originated call the IMSI or TMSI is sent 
in a CM Service Request Message; 
in a Mobile Terminated call the IMSI or TMSI is sent 
in a Paging Response Message; 
in a call re-establishment the IMSI or TMSI can be 
sent in a CM-Reestablishment request message; 
and 

in a Location Update the IMSI or TMSI can be sent 
in a Location Updating Request message. 

The IMSI/TMSI used in the above procedures needs to 
be stored for the length of the procedure, in case an 
Identity Request/Response signaling exchange hap- 
pens during the procedure. This Identity Request/Re- 
sponse signaling exchange can happen at any time dur- 
ing the transaction between the mobile station and the 
BTS. 

Under normal circumstances no transactions can 
take place between the mobile station and tho BTS un- 
less the handset has a SIM card inserted. Thus, the IM- 
SI/TMSI is normally used in any transactions to identify 
the user to the network. However, GSM allows a user to 
make a call to the emergency services using a handset 
with no SIM inserted. In this case the handset uses its 
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I ME I in the CM Service Request message sent to the 
network Gnnorally, this is the only case when the IMEI 
is used in the Initial Layer 3 message. 

Another method of obtaining the IMEI is to use the 
GSM identity known as an International Mobile Equip- 5 
ment Identity with Software Version number (IMEISV). 
This number is essentially the IMEI with an extra field 
containing the version number of the software control- 
ling operation of the handset. The Cipher Mode Com- 
mand message sent from the BSC to the BTS can ask 10 
for the IMEISV to be sent from the mobile station to the 
network In response the IMEISV is sent from the mobile 
station to the network in a Cipher Mode Complete mes- 
sage This Cipher transaction can take place in any two- 
way communication between the mobile station and the is 
network 

Variants 

Various modifications are : of course, possible to the 20 
above dcbunbixJ method for tracking identity-code 
changes. For example, the table 61 could be split into 
subtables. one lor each location area or association 
means other than a table data structure could be used 1. 
to associate an I MSI with the current corresponding TM- 25 
SI. Again, rathor than explicitly looking for connection 
release messages to trigger removal of the connection 
records 54 : provided the SCCP local references were 
made unique over a given time period greater than the 
maximum expected duration of a transaction, the re- 30 
moval of a record could be arranged to occur after a pre- 
determined interval less than said given time period but 
longer than the usual maximum connection duration (in 
fact, having a time out for record removal may, in any 
case : be a useful housekeeping measure). 35 

In certain circumstances the initial correlation be- 
tween a user's I MSI and the current TMSI can be estab- 
lished from the contents of a BSSMAP Paging Request 
message, which is transmitted by the PLMN to locate a 
mobile station to which an incoming call is to be con- 40 
nected. This Paging Request message usually contains 
both .the IMSI and the. current. TMSI, and thus readily 
enables their association to be identified. 

Although in the above-described embodiments of 
the identity-tracking apparatus signalling messages re- 45 
lating to the same transaction have been related through 
a single parameter value (a SCCP end reference for the 
first embodiment and channel number for the second 
embodiment), it will be appreciated that in suitable cas- 
es different parameters or combinations of parameters so 
could be used. 

With regard to tracking across handovers, it will be 
appreciated that rather than having the central station 
42 carry out the correlation process, each monitor 40 
can be arranged to carry out this correlation for its new 55 
SCCP connections (A interface) or channel numbers 
(Abis interface); in this case, each monitor 40 will send 
out Correlation Old messages to all other monitors and 



the Correlation New and Correlation Complete messag- 
es will no longer be required, 

The identity tracking method can, of course, be ap- 
plied to any appropriate cellular radio system and is not 
restricted in application to GSM-type systems. Indeed, 
the tracking method can be applied to other types of 
communications system where identity codes and tem- 
porary identity codes are employed. Changes in identity 
code could be initiated from the user rather than from 
the communication network though in this case appro- 
priate precautions would need to be taken to preserve 
uniqueness. 

One possible application of the tracking method to 
a system other than a mobile system is to monitoring 
Internet-originating traffic passing into a PSTN; due to 
the insecure nature of the Internet, there may be a need 
for temporary identities to be assigned in the same way 
as for mobile systems and in this case the present track- 
ing method would be of value in tracking user identity. 

Claims 



A method of tracking identity-code changes in a 
communications system in which a plurality of user 
stations can simultaneously conduct respective 
communication transactions during which signal- 
ling messages are exchanged with the remainder 
of the communication system over at least one sig- 
nalling path of a signalling subsystem of said com- 
munications system, said signalling messages in- 
cluding first messages sent by said user stations 
and each including an identity code associated with 
the user station sending that message, and second 
messages specifying corresponding identity codes 
for particular user stations; said method comprising 
the steps of: 

(a) - monitoring said signalling subsystem to 
detect a said first message; 

(b) - extracting from the said first message de- 
tected in.step (a), the said identity code includ- 
ed therein; 

(c) further monitoring said signalling subsystem 
to detect a said second message related to the 
same communication transaction as the first 
message detected in step (a); and 

(d) upon detection in step (c) of said second 
message, recording the identity code specified 
therein as the identity code corresponding to 
the identity code extracted in step (b). 

A method according to claim 1 , wherein stop (c) in- 
volves detecting signalling messages relating to the 
said same communication transaction by looking on 
a specific said signalling path for signalling messag- 
es that have at least one particular parameter value 
which is at least temporarily characteristic of said 
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same communication transaction on said specific 
signalling path, said at least one particular param- 
eter value being determined from at least one sig- 
nalling message previously detected on said spe- 
cific signalling path as related to said same commu- 
nication transaction, and said specific signalling 
path being at least initially the signalling path on 
which said first message is detected in step (a). 

3. A method according to claim 2, wherein said at least 
one particular parameter value is at least initially ex- 
tracted from said first signalling message detected 
in step (a). 

4. A method according to claim 2, wherein step (c) fur- 
ther involves detecting any change in signalling 
path carrying said signalling messages related to 
said same communication transaction, said specific 
signalling path corresponding to the signalling path 
currenlly detected as carrying these signalling mes- 
sages. 

5. A method according to any one of claims 2 to 4, 
wherein said at least one particular parameter value 
is the same for all signalling messages that appear 
on said specific signalling path and relate to said 
same communication transaction. 

6. A method according to claim 5, wherein a connec- 
tion-oriented service is established across a said 
signalling path in respect of each said communica- 
tion transaction handled thereby, said at least one 
particular parameter value being an end point ref- 
erence for said connect ion -oriented service. 

7. A method according to claim 6, wherein said com- 
munications system is a mobile radio system of the 
GSM type, each said at least one signalling path 
being across an A interface and each said connec- 
tion-oriented service being provided by an SCCP 
connection. 

8. A method according to any one of claims 2 to 4, 
wherein said at least one particular parameter value 
characteristic ot said same communication transac- 
tion is subject to change in response to a said sig- 
nalling message on said specific signalling path, 
step (c) further involving: 

detecting any change in said at least one par- 
ticular parameter value by detecting the said 
signalling message provoking that change, and 
using the latest detected value ol said at least 
one particular parameter value in looking for 
further signalling messages on said specific 
signalling path that relate to said same commu- 
nication transaction, 



9. A method according to claim S. wherein said com- 
munications system is a mobile radio system of the 
GSM type, each said at least one signalling path 
being across an Abis interface and said at least one 

5 particular parameter value being a channel identifi- 
er tor identifying the radio channel associated with 
the transaction. 

10. A method according to claim 1, wherein said com- 
io munications system is a mobile radio network in 

which users have respective unique identity codes 
and said user stations are mobile stations that com- 
municate over radio channels with a fixed network 
part forming said remainder of the communications 
is system, said identity code included in a said first 
message being one of: 

- the said unique identity code of a user associ- 
ated with the said user station sending that first 

20 message; and 

— a temporary identity code assigned by a said 
second message sent to said user station. 

11. A method according to claim 2, including the step 
25 of generating a record for said specific signalling 

path associating the identity code extracted in step 
(a) with the current said at least one parameter val- 
ue characteristic of said same communication 
transaction on said specific signalling path, step (d) 
30 involving associating the identity code specified in 
the second message with said record. 

1 2. A method according to claim 1 1 , comprising the fur- 
ther step of monitoring said specific signalling path 

35 to detect termination of said same communication 
transaction and thereupon removing said record. 

1 3. A method according to claim 1 , wherein said signal- 
ling subsystem has a plurality of said signalling 

^0 paths, said method involving carrying out steps (a) 
and (c) for at least some of these signalling paths, 
and the operation in step (d) of recording said iden- 
tity code corresponding to the identity code extract- 
ed in step (b), involving generating a report includ- 
es ing both these identity codes and sending this report 
to a station, this station being the same for all mon- 
itored signalling paths. 

14. A method according to claim 10, wherein the oper- 
50 ation in step (d) of recording said identity code cor- 
responding to the identity code extracted in step (b), 
involves using these identity codes to maintain as- 
sociation moans associating monitored said unique 
identity codes with the corresponding current said 

55 identity codes. 

15. A method according to claim 10, wherein said sig- 
nalling subsystem has a plurality of said signalling 
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paths, said method involving carrying out steps (a) 
and (c) for at least some of these signalling paths, 
and the operation in step (d) of recording said iden- 
tity code corresponding to the identity code extract- 
ed in step (b), involving: s 

- generating a report including both these identi- 
ty codes and sending this report to a station, 
this station being the same for all monitored sig- 
nalling paths; io 

- receiving said reports at said station and using 
the identity codes included therein to maintain 
association means associating said unique 
identity codes reported to the station with the 
corresponding current said identity codes. is 
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spective unique identity code for a mobile station. 

19. Apparatus for tracking identity-code changes in a 
communications system in which a plurality of user 
stations can simultaneously conduct respective 
communication transactions during which signal- 
ling messages are exchanged with the remainder 
of the communication system over at least one sig- 
naling path of a signalling subsystem of said com- 
munications system, said signalling messages in- 
cluding first messages sent by said user stations 
and each including an identity code associated with 
the user station sending that message, and second 
messages specifying corresponding identity codes 
for particular user stations; said apparatus compris- 
ing: 



16. A method according to claim 10, wherein the cov- 
erage of said mobile radio network extends over a 
plurality of location areas, said temporary identity 
codes being assigned uniquely wilhin each such ar- 20 
ea and certain of said signalling messages sent by 
said user stations including location information 
identifying the location area in which the user sta- 
tions are respectively located; said method includ- 
ing the stop of monitoring said signalling subsystem ss 
to identify from said certain signalling messages the 
current location area of the user stations partaking 

in said communication transactions, and where the 
corresponding identity code recorded in step (d) is 
a said temporary identity code, recording the loca- 30 
tion area of the corresponding user station along 
with that corresponding identity code. 

17. A method of monitoring usage behaviour of a par- 
ticular user of a mobile radio network, said method ss 
involving: 

(i) tracking identity-codes changes in accord- 
ance with the method of claim 14; 

(ii) starting with the said unique identity code of 40 
said particular user, identifying from said asso- 
ciation means the corresponding current iden- 
tity code of that user; and 

(iii) monitoring said signalling subsystem to de- 
tect first messages including the said corre- 45 
spending current identity code identified in step 

(ii), and recording predetermined parameters of 
the communication transactions of which these 
first messages form a part. 

so 

18. A method according to claim 1 , wherein said com- 
munications system is a mobile radio network in 
which said user stations aro mobile stations which 
have respective unique identity codes and which 
communicate over radio channels with a fixed net- ss 
work part forming said remainder of the communi- 
cations system, one of said identity codes included 

in said first and second messages being said re- 



first monitoring means for monitoring said sig- 
nalling subsystem to detect a said first mes- 
sage; 

first extracting means for extracting from a said 
first message detected by said first monitoring 
means, the said identity code included therein, 
second monitoring means for further monitor- 
ing said signalling subsystem to detect a said 
second message related to the same commu- 
nication transaction as said first message de- 
tected by said first extracting means, and 
second extracting means for extracting from a 
said second message detected by said second 
monitoring means, the identity code specified 
in that second message as the identity code 
corresponding to the identity code extracted by 
the first extraction means. 
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(54) Method and apparatus for tracking identity-code changes in a mobile communications 
system 



(57) In a mobile radio network such a GSM network, 
an operative identity code is passed by a mobile station 
to the fixed network part at the start of each communi- 
cation transaction. This operative identity code will ei- 
ther be the unique identity code (IMSI) assigned to the 
mobile-station user or, more usually, a temporary, sub- 
stitute, identity code (TMSI) allocated by the fixed net- 
work part with a view to obscuring the identity of the user 
to anyone monitoring the network radio traffic. Whilst the 
fixed network infrastructure knows the association be- 
tween a temporary identity code (TMSI) and the corre- 
sponding unique identity code (IMSI) of a user, this in- 
formation is generally not readily accessible. To enable 
the current temporary idenlily code (TMSI) of a user lo 
be readily tracked without burdening the network infra- 
structure, a monitoring arrangement is provided which 
monitors network signalling messages to link the differ- 
ent messages associated with a particular user mobile 
station that separately give the current operative identity 
code (line "c") and assign a successor operative identity 
code to that user (line "h"). In one embodiment applica- 
ble to a GSM network, messages on the A interface that 
carry identity code information for a particular user dur- 
ing a communication transaction are linked through the 
local references of the SCCP connection established for 
the transaction. In a second embodiment, also applica- 
ble to GSM, messages on the Abis interface are moni- 



tored and linked through the channel numbers con- 
tained in these messages. 
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